Electronic kiosk authoring system

ABSTRACT

An authoring system for use in developing and maintaining user interface screens for computer-based information delivery systems. The authoring system enables the user interface for each individual computer to be customized quickly and easily within wide limits of variation, yet subject to constraints adhering the resulting interface to good standards of aesthetics and user friendliness. The system may be used to provide custom interfaces expeditiously even for hundreds of computers presenting information from numerous independent information sources. The authoring system uses the methods of object oriented programming to define specialized object classes for instantiation on individual computer interface screens subject to pre-defined limitations on variability. Links are provided to an appropriate database for multimedia presentations on an interface screen of content bearing information from the information providers.

BACKGROUND OF THE INVENTION

The present invention relates generally to electronic informationdelivery systems and more particularly to distributed electronic kiosksystems with multiple kiosk sites for presenting myriad amounts ofinformation to users.

An electronic kiosk refers to a computer-based information deliverysystem generally accessible to some segment of the public for retrievinginformation or initiating transactions. An individual kiosk unitincludes a display screen for presenting information to the user andsome form of computer input device for the user such as a touch screenor keypad, although a full keyboard or mouse could also be provided. Thetype of kiosk system of interest here is an interactive system havingmultiple kiosk sites at which a user at an individual kiosk can select atopic or search for information about a topic from a large database ofinformation.

Such kiosk systems have become popular in recent years. They are found,for example, at museums and exhibitions, airports, public transportationstations, banks, and even in retail establishments for the use ofcustomers. Examples of kiosk systems are disclosed in U.S. Pat. No.4,817,043 of Brown, U.S. Pat. No. 4,974,170 of Bouve et al., and U.S.Pat. No. 5,237,157 of Kaplan. Recently multimedia kiosks have appearedpresenting information to the user not only as text on the displayscreen, but also in the form of graphics, audio clips, animatedsequences of still images, and even video clips. The travel agencyThomas Cook, for example, has introduced a multimedia kiosk forarranging holiday travel, reported in Which Computer?, August 1994,pp.40-41.

The present invention addresses the development of an electronic kiosksystem comprising a large number of individual kiosks located at avariety of different sites for providing a selection of informationcustomized to each site. For purposes of illustration the presentinvention is discussed in the context of a kiosk system serving ageographical region popular for skiing. Kiosks may be located, forexample, at individual ski areas, at hotels and resorts in the area, andat ski shops and other retail shops. The information available to a userat an individual kiosk will depend on the nature of the establishment inwhich the kiosk is located. A kiosk at a ski shop, for example, mayprovide information about the lines of rental equipment available at theshop and may also provide information about the local ski areas, skiconditions, and even local restaurants and events. Kiosks at differentski shops would have to be customized for each shop at the least becauserental equipment will generally differ from shop to shop. A kiosk at alocal hotel may also provide information about the local ski areas, skiconditions and events, and may provide information about the ski shopsin the area that rent and sell ski equipment. The hotel kiosk wouldgenerally not provide information about other hotels in the area and mayor may not provide information on restaurants outside the hotel. A skiarea kiosk may provide information on lift tickets, ski conditions,specific ski runs, ski school and day care, as well as information onski rental, shops, restaurants, local events and the like. In a regionencompassing several ski areas and towns with numerous shops,restaurants, places to stay, and places of sightly entertainment, such akiosk system could include hundreds of kiosks, each having its own userinterface and presenting its own unique selection of information.

The custom design of each individual kiosk can be a formidableundertaking. There are a great variety of possibilities for laying outthe user interfaces, especially for a multimedia kiosk. A ski shopkiosk, for example, may want to display an initial stylisticpresentation of the ski shop's name, perhaps overlaid on a graphic imageof a skier executing an exciting ski maneuver. For a line of specializedrental skis the kiosk may present a video clip, perhaps accompanied byan audio clip, showing the ski in its specialized use. For informationon a restaurant the kiosk may display a graphic image depicting patronsin the restaurant to show the atmosphere and dress appropriate to therestaurant. The kiosk may also display the restaurant menu either as acomputer text file or as a graphic image of a stylish menu used in therestaurant.

These examples demonstrate the great variety of user interfacesavailable and highlight the effort required to develop a customizedinterface for each kiosk. The problem is intensified because each kioskinterface will generally have to be changed from time to time eithersporadically or at regular intervals. For example, a kiosk that displaysa graphic image of patrons at a restaurant to show the atmosphere andappropriate dress may find it desirable to change the graphic image withthe season since a scene showing winter dress would not be appropriatein the summer. A ski shop may not carry precisely the same lines ofequipment from one season to the next, and its kiosk will have to bemodified to show the current equipment. Sometimes more extensivemodification will be needed. A shop that carries ski equipment in thewinter may specialize in other activities in the summer, for example,tennis, golf, swimming, boating or hiking. The kiosk's user interfacewould have to be extensively revised with the changes in season toreflect the shop's new emphasis and goods, and the information contentavailable to the kiosk would have to be updated to include thesummertime goods and activities. A shop or hotel that displaysinformation on ski areas in the winter may want to display informationabout tennis, golf and other outdoor activities in the summer. In anyone geographical region changes of this sort may have to be made tohundreds of kiosks or more.

Some of the problems to be overcome to make a kiosk system of this sortcommercially viable are the organization of the data for potentiallyhundreds of kiosks and even more data sources so that a customizedselection of data will be accessible to users at each of the kiosks; thecustomization of the user interface for each of the potentially hundredsof kiosks or more in the system in a manner that is economicallyfeasible; the ability to update the data available to the kiosks quicklyand easily; and the ability to modify the user interface of any onekiosk quickly and easily.

The organization of data for kiosk systems and the form of the userinterface are active areas of study, in which no consensus has yet beenreached; See, for example, Y. Guang et al., “Driving theCitizen-Oriented Information on the Electronic Highway,” Proceedings ofthe International Conference on Multimedia Computing and Systems, May15-18, 1995, IEEE Computer Society Press, pp. 131-138; G. Kearsley andR. S. Heller, “Multimedia in Public Access Settings: Evaluation Issues,”Journal of Educational Multimedia and Hypermedia, Vol 4, No. 1, pp.3-24; W. Holfelder and D. Hehmann, “A Networked Multimedia RetrievalManagement System for Distributed Kiosk Applications,” Proceedings ofthe IEEE International Conference on Multimedia Computing and Systems,May 15-19, 1994, pp. 342-351; P. Steiger, “MINNELLI—Experiences with anInteractive Information Kiosk for Casual Users,” Proceedings of theUBILAB Conference 1994 (Switzerland), Computer Science Research atUBILAB, pp. 124-133.

To assist in creating and modifying computer interface screens, a numberof commercial authoring software products are available. With suchsoftware a programmer can design the layout of a display screen such asthe size, character and placement of buttons and windows on the screenand combine text, graphics, audio and video into a user-friendlyapplication screen interface. In general, authoring tools compriseprewritten computer code having a functionality for reading a datastructure that defines a task to be taken and performs the task based onthe data. Examples include Macromedia Director, Asymmetrix MultimediaToolBook, and Oracle's Media Objects. High-end authoring systems havethe capability to integrate different media and they include fullapplication-building programmability similar to that found in databasepackages. Most authoring tools define a screen and the specificattributes of the screen such as the definition of a video window thatwill play a specified video clip or show a text file or a graphic image.

SUMMARY OF THE INVENTION

The present invention provides a multimedia kiosk authoring system foruse in developing and maintaining multimedia kiosk systems. Theauthoring system enables the user interface for each individual kiosk tobe customized quickly and easily within wide limits of variation, yetsubject to constraints adhering the resulting interface to goodstandards of aesthetics and user friendliness. The system may be used toprovide custom interfaces expeditiously even for hundreds of kiosks. Theauthoring system also provides for organization of information fromnumerous information sources, referred to herein generally asinformation providers. The system makes it easy to set up, maintain, andupdate a great variety of kiosks with large amounts of informationpotentially available to each kiosk. Each kiosk, however, is customizedto present only the information that is appropriate to that kiosk. Whena new information provider subscribes to the system, it may easily beincorporated into the system so that it is available for all kiosks. Allindividual kiosks may have available to them the entirety of the latestinformation. The present authoring system avoids the need to keep trackof different versions in the field at potentially hundreds of kiosksites.

The present authoring system is particularly advantageous in that it maybe used by persons with little or no experience in the intricate detailsof computer programming thereby making it easier for a larger number ofpersons to set up kiosk interface screens. It is a further advantage ofthe present authoring system that an individual using the authoringsoftware to devise a kiosk interface screen (that individual is referredto herein as a “system author”) is only given a limited range of choicesfor stylistic and functional elements appearing in the screen displays.In this way major aesthetic or functional design choices such as buttonsyles and sizes, window borders, color combinations, and type fonts aswell as hierarchical methods of retrieving information may be built intothe system taking into account the considered opinions of aestheticdesign specialists, database specialists, and academic studies on publicaccess kiosk systems and user preferences and problems. Only a limitedrange of pre-defined design choices is then made available to a systemauthor. Nevertheless, the authoring software is structured to make itamenable to change for example to permit new elements to be added to thesystem or to take into account the results of new studies on userinteractions with computer kiosks.

Other aspects, advantages, and novel features of the present authoringsystem are described below or will be readily apparent to those skilledin the art from the following specifications and drawings ofillustrative embodiments.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagrammatic representation of a distributed kiosk systemfor implementing the present invention.

FIGS. 2A and 2B are examples of kiosk screen display layouts.

FIG. 3 is an example of a screen layout joined table for implementing akiosk authoring system of the present invention.

FIG. 4 is an example of a Region/Resort database joined table.

FIG. 5 is an example of a Shop/Manufacturer database joined table.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

For purposes of illustration an embodiment of the present invention isdescribed in a distributed kiosk system serving a geographical regionpopular for skiing. FIG. 1 shows three representative kiosks 10 locatedin a ski shop (the “ABC Ski Shop”), a ski area (the “Big Mountain SkiArea”), and a hotel (the “ZZZ Hotel”), all located in a geographicalregion indicated generally at 11. FIG. 1 shows a representativegeographical region situated in the ski country of Northern California.The system is not limited to small numbers of kiosks, but may includehundreds or thousands of kiosks serving a number of localizedgeographical regions. Indeed, many of the features of the invention areespecially advantageous in such large and widely distributed systems.The system may also include remote and isolated kiosks such as kiosk 12located in a travel bureau removed from ski country 11. The embodimentof FIG. 1 includes a master computer 13 at yet another location that maybe used for software implementation of new subscriber kiosks on thesystem and maintenance of old kiosks.

Kiosks commonly take the form of dedicated stand-alone stations having adisplay screen that may be a touch screen and/or may be used with akeypad. In some settings, however, a self-contained stand-alone kioskwould be out of place and the function of the kiosk may be servedequally well by a desktop computer with a touch pad or mouse or even akeyboard. For example, kiosk 12 of FIG. 1 in a remote travel bureau maytake the form of a desktop computer in the travel bureau office. “Kiosk”is used herein in this broad sense to include stand-alone kiosks as wellas general purpose computers configured to serve the same functions as astand-alone kiosk. As configured in the present system each kiosk alsoincludes its own data storage capability such as a high volume hard diskdrive, although the system could operate from a central database serversuch as master computer 13 in FIG. 1 when suitable bandwidth forcommunications with the many kiosks is available. As will be describedbelow, if the system is not implemented with a central database server,it is advantageous for each kiosk to store the entire database ofinformation for all kiosks in the system even though each kiosk will notgenerally use the entire database.

Hardware implementations of a kiosk as a stand-alone unit with a touchscreen or keypad are well known and need not be described in detailhere. Of more significance to the present invention is the method bywhich the software for the kiosk units is configured.

Before the software is described in any detail, it is instructive tolook at examples of kiosk screen layouts designed by the authoringsystem of the present invention. FIG. 2A shows a representative layoutof a display screen 20 from the ABC Ski Area kiosk 10 that is rich instructural details. One column and one row of buttons 21 of a first typeare disposed along two edges of the screen. Each button 21 has a textualportion 22 with text identifying a category of information and agraphics portion 23 showing a graphical image appropriate to theassociated information category. The bulk of the screen is occupied by amain window 24 that has a variable display. When the kiosk is not inuse, window 24 may display a primary scene from the ski area withoverlaid text identifying the area and perhaps giving instructions foruse. When a user activates a button 21, main window 24 displaysinformation about the topic associated with the button. In FIG. 2A theuser has activated the restaurant button in the upper left corner of thescreen. Main window 24 displays a background graphical image of anattractive scene from the ski area overlaid with three columns ofbuttons 26 of a second type with textual labels 27 identifyingrestaurants and other eating establishments available at the ski area.Also overlaid on the background image in main window 24 are textuallabels 28 identifying the general locations of the eatingestablishments. At the bottom of the screen are additional screenmaneuvering buttons 29. For purposes of illustration in FIG. 2A thegraphical images on buttons 21 and in main window 24 are shown only indiagrammatic format. The authoring software can insert a variety ofimage types at the selection of the system author such as photographs,artwork or even video clips.

A closer look at the structure of the screen layout of FIG. 2A is inorder. The buttons 21 have a fixed predefined size, which is chosen notonly to make them aesthetically pleasing in appearance, but also easy touse on a touch screen by persons generally unpracticed with touch screenoperation. The button placement in FIG. 2A is generally fixed along twoadjacent edges. This is an aesthetic choice, but it is a choice that isforced by the authoring software to assure that once an aestheticallyand functionally acceptable button size and layout has been chosen, itwill be maintained throughout all further screen layouts for all kioskswithout having to expend time and effort re-creating an acceptablebutton layout anew for each kiosk. Other aesthetic button layouts mayalso be used, but once a general button layout is devised, the softwaremakes it available for use in all kiosk interface screens. Consideringthat many many screen layouts will generally have to be set up and thenregularly revised, limiting the system author's freedom to devise newbutton patterns and button styles greatly enhances the ease with whichnew kiosks may be brought in operation and ensures that the buttonpattern will be aesthetically and operationally acceptable.

The screen layout of FIG. 2A shows twelve buttons 21 of the first type.If a kiosk screen calls for fewer buttons, then the spacing between thebuttons is automatically adjusted, but the button size and row andcolumn placement are unaltered. If the screen calls for more buttons,then one button on the initial screen is a “MORE” button activatingdisplay of additional buttons, which will then include a “BACK” buttonfor return to the previous display of buttons. This is an example of acontrol built into the authoring software to ensure that the buttonscannot be made too small so as to impair their readability or ease ofuse.

Notwithstanding the frequent advantages of the fixed geometric buttonplacement as in FIG. 2A, an alternative free button placement is alsoprovided as illustrated in the screen layout of FIG. 2B. This isparticularly beneficial when only a few buttons 21 are to be displayed.FIG. 2B shows an alternative screen layout with a main window 24 a andthree buttons 21 a of the first type positioned at coordinates and inorientations specified by the system author. The buttons 21 a activateassociated displays in main window 24 a.

Having described the appearance and basic functionality of example kioskinterface screens, a more detailed description is now given of animplementation of the authoring system according to the invention. Agiven screen will include a variety of elements for presentation to auser such as one or more windows, one or more background images orartwork for providing a backdrop for a window or for background within awindow, a number of buttons, a number of “hot spots,” i.e., areas on thescreen for activating actions, text strings, video clips, audio clips,slide sequences, or animation sequences. These elements are grouped intoelement types. For example, there may be several styles of buttons, eachstyle constituting a button type, or there may be several styles ofwindows, each constituting a window type. Thus, the element types mayinclude one or more button types, window types, text types, video types,and so on. Buttons and hot spots are sometimes referred to hereincollectively as activation sites, and button types and hot spot typesare sometimes grouped together herein as examples of activation types.

The authoring system uses the methods of object oriented programming.The system is specified by the following Object Class Definition Tables.The entries in these tables follow customary object oriented programmingnomenclature and will be readily understood to those skilled in the artof object oriented programming. The particular implementation describedhere was developed for the Microsoft Windows® platform using theMicrosoft Software Developers Kit (SDK) and that nomenclature isfollowed here. The classes used here are derived from or supplementclasses provided by Microsoft SDK. Attibute Attribute Type NameDescription Project Class: long IProjectID Project ID CStringsProjectName Project Name long IHomeScreenID ID of the Home Screen forthe Project - not known initially CString sHomeName Name of the HomeScreen Type Name Description Screen Class: long IScrnID Screen IDCString sScrnTitle Screen Title CString sScrnBkgnd Screen Background -File Name long IScrnColor Screen Color long IProjectID Project ID longIParent Parents ID long[ ] IChildren[ ] Array of Children ID's intnTransition Transition effect for screen to screen CString sVoiceOverVoice Over file name associated with screen CString sHelpFile Help Filename associated with the screen Control Class: long IScreenID Screen ID;every control is associated with a screen long ICtrlID Control ID; everycontrol has a unique ID long IForeColor Foreground Color; foregroundcolor of the control long IBackColor Background Color; background colorof the control long ILink Link; ID of screen to which control is linkedWORD wTransition Transition; #define describing screen transition effectPOINT ptControlLt Upper left hand corner of control POINT ptControlRtLower left hand corner of control WORD wHeight Control Height WORDwWidth Control Width double dRotate Angle of control in radians BOOLbAuthor Author Mode (T) Authoring (F) playback engine BOOL bActionAction; specifies if a control has an action (T) or a Link (F) longIAction Action ID; a #define describing the Action Button Class: WORDwButtonType Type of button WORD wFrameStyle Frame Style long lFrameColorColor of the frame WORD wFrameSize Frame size in pixels CString sTitleTitle of button WORD wLocation Location of title on button longlTitleColor Color of the Button Title CString sFont Font Name BOOL bBoldFont Attrib - Bold BOOL bItalic Font Attrib - Italic WORD wPtSize Fontpoint size long lDropColor Drop Shadow Color WORD wDropSize Drop shadowsize CString sFile File Name for image (if one used) CPoint ptPictLeftUpper left hand corner of Image Cpoint ptPictRight Lower right handcorner of image WORD wWidth Width of image WORD wHeight Height of imageWORD wState Button State int nYOffset Image Y Offset int imghandleHandle to the image Text Window Class: HWND hWndTextWin Handle to aCRichEditTextControl CRECT cRectWin Coordinates of the Window CStringsTxtFile Name of the RTF to display long lBkColor Background Color ofthe control LOGFONT lfText Provide a LOGFONT if text is not tb displayedas it is stored in the RTF File. BOOL bBorder Display Window BorderDWORD dwStyle Window Styles DWORD dwBorder Border Style BOOLbTransparent Display the Text Transparently with no Frame, etc. on theparent window Text Object Class: CString sText Text to display CPointptText Upper Lt Coordinate of Starting Location to Display Text doubledRadian Angle if any to display Text DWORD dwEffect Effect to use toDisplay Text LOGFONT lfText LOGFONT structure to be used to display theText Audio Object Class: CString sWavFile Name of the WAV File to play.A wav file is assumed but other audio file formats like MPEG, AVI, aresupported. The file type is based on the file extension. WORD wDelayDelay as to when to start the Audio BOOL bRepeat Set to true to replaythe Audio clip when complete BOOL bVolControl Set to true to allow userto alter Audio & even mute Audio. Video Object Class: CString sVideoName of the video file to play. Again, the Video type is determined bythe files extension. CRect cRectWin Rectangle of where to place theVideo Window. BOOL bRepeat Set True to Repeat the Video when completeBOOL bAudio Set True to play Audio UINT uiEffects Effect to play betweenClips BOOL bMultiple Set to true if there are multiple clips to playspecified in CString. If there are multiple clip then CString is a filewith a list of clip names. BOOL bBorder Set to True if there is a BorderDWORD dwBorderStyles Style of Border to use on the Video Window BOOLbOpen Set to True if we should provide File Open Capability. BOOLbControl Set to Ture if MCI control functionality is provided, such as aslide bar, repeat, stop. Animation Object Class: CString sAnimation Nameof the animation file to play. Again, the Animation type is determinedby the files extension. CPath cPathAnim Path of the Animation BOOLbRepeat Set True to Repeat the Video when complete BOOL bAudio Set Trueto play Audio BOOL bMultiple Set to true if there are multiple clips toplay specified in CString. If there are multiple clip then CString is afile with a list of clip names. DWORD dwBorderStyles Style of Border touse on the Animation Window Image Object Class: CString sImage Name ofthe Image file to display. Again, the image type is determined by thefile extension. BOOL bBorder DWORD dwStyle Image Style Attributes, likeborder size, border color, Drop Shadow, Transparency CPoint ptUpperLtUpper Left Corner of the Image UINT uiWidth Width of the Image UINTuiHeight Height of the Image double dAngle Angle to display the ImageCRECT[ ] rectHot Array of Rect Hotspots in the Image Slide Object Class:CString sFiles A File containing the images to display in the slidewindow. BOOL bDistort Set to true if Images can be distorted whendisplayed BOOL bBorder Set to True if the Object has a border DWORDdwStyles Sets the Objects Styles, such as border size, border color,Forward and Backward Buttons provided UINT uiDelay Delay between slidesCPoint ptUpperLt Upper Left Corner of the Image UINT uiWidth Width ofthe Image UINT uiHeight Height of the Image double dAngle Angle todisplay the Image Nav Object Class: CString sFile Name of the Nav FileCRect cRectWin Rectangle of location for control BOOL bBorder Set toTrue to display a border. DWORD dwStyles Styles for the Control, likeborder size, border color CRect[ ][ ] cRectNav Array of Hotspots for theNav, Store X and Y for Hotspots. The frames will be determined on thefly.

The project class defines the types of pre-established projects that areavailable to be implemented on a kiosk system. “Project” here refers toa kiosk system implementation devoted to a specific theme; for example,the kiosk system based on a skiing theme illustrated here is an exampleof a ski implementation and constitutes one project. Other projectscould be for example a golf project or a mountain biking project. Inshort, “project” refers to a grouping of a series of screens with acommon theme. A project is associated with a home screen with which afull set of screens for the project is linked.

The screen class is associated with all the controls for a given screen.All the classes are derived from the control class, which defines thecommon attributes that all classes may share. The attribute “bAuthor” inthe Control Class Definition Table defines two modes of operation. Inthe author mode a sysem author can manipulate the various elements to beplaced on a screen, such as placing buttons or editing attributes withinthe permissible attribute ranges. In the playback mode the system authorcan play back the current configuration of a screen as it will bepresented to a user. Note in the Control Class Definition Table thatsince the defining points for controls do not have to be rectangular,points may be used to support non-rectangular objects. The button classis derived from the control class. For the text window class the controlis derived from a CRichEditTextControl class, which is a class providedwith the Microsoft Windows SDK. This class handles predetermined logicfor handling rich text format (RTF) text such as word wrapping or fontselection. In this table “LOGFONT” refers to a structure provided byWindows SDK for defining a font and its attributes. The attribute“bTransparent” enables the system author to display text in a windowwithout displaying the window itself. That is, the window istransparent, the text is not. This provides an alternative means offormatting text other than using a text object. Using a transparentwindow makes it easier to format large amounts of text to control wordwrap, highlighting and the like. The use of RTF format can be convenientfor example to display text with predetermined characteristics. Forexample, it may be desirable to display a ski report with a standardizedfont with keywords (e.g. Excellent Conditions, Poor Conditions, Warning)highlighted or offset in different colors. Through this class the formatfor presentation may be pre-established for the system author. In theText Object Class Definition Table the attribute “dwEffect” refers tothe choice of dynamic transitioning effect (fading and the like) to beused, if any, when the text is first displayed on (or removed from) thescreen. The audio object class is used for presenting audio clips to theuser. The table entry “wDelay” refers to the delay before an audio clipbegins to play after a kiosk user activates it. In the Video ObjectClass Definition Table the entry “uiEffects” refers to a dynamictransitioning effect to activate between between video clips when morethan one video clip is to be played sequentially or one video clip is tobe repeated. The entry “bOpen” refers to the ability of a kiosk user toopen a video clip by activating an activation site on a screen. Theentry “bControl” puts up a media control interface including buttons andslide bar for a kiosk user to start, stop, and fast-forward and backwithin a video clip. In the Animation Object Class Definition Table theentry “cPathAnim” defines a stored array of points defining a locus foran animation sequence to follow across in display screen as the sequenceprogresses. For example, an animation sequence could move along anelliptical path as the clip is played. The image object class definesimage objects to be used as stills for backgrounds or for foregrounds,for example, a product image such as a ski boot and images to be used aspart of a sequence for slide presentations. The nav object class refersto navigable objects. For example, a kiosk user may be permitted tonavigate an image of a product such as a ski boot. The boot is stored asa series of still images from different angles collected together in anarray. A kiosk user may activate controls to look at the front, side orback of the ski boot.

The authoring software includes the capability of including hot spots ina navigable object so that the user may obtain further information oractivate further screens. For example, a buckle on the ski boot mayconstitute a hot spot that the user can activate to get more detailedviews of the buckle or to activate a video clip of the operation of thebuckle. To make it easier and quicker for a system author to define suchhot spots, the authoring system proceeds as follows. A region to bedesignated a hot spot is defined on only one image, referred to hereinas “hot spot defining” image. If a further hot spot to be defined is notvisible in the first hot-spot-defining image, then a second image willalso be designated a hot spot defining image. The hot spot locations onthe hot spot defining image or images are stored in a lookup table. Whenthe user rotates a view (that is to say, progresses to a further imagein the navigable sequence) and attempts to activate a region on therotated view, the software operates to back track to the hot spotdefining image from which the current image unfolded and looks up thecoordinates for any hot spots defined in that image. The appropriateaction is then taken. This procedure represents a considerable savingsfor the system author in a kiosk system having hundreds of kiosks andmany navigable objects. It is not necessary for the system author todefine separate hot spots on each image in an array making up anavigable object.

The interrelations amongst the object classes in a system implementationis shown the joined tables of FIG. 3. This series of tables describesthe relationship of a project, the screens, and the screen objects. Thescreen layout tables also define screen types and the locations at whichobjects appear on screens of given type. For example, a screen of type 1will have its own associated screen definitions with one object to apre-defined limiting number N of objects. A screen of type 1 may then bedefined having from one to N objects and the objects will always beplaced appropriately. Some example tables will now be discussed.

Project Table:

The project table contains a unique project ID, the project name, thehome screen ID and the Home Screen Name. All screens in the system arenecessarily linked to a specific project. Example: Project ID: 004989788Project Name: Ski Home Screen ID: 004000001

Home Screen Name: HomeScreen

The project ID is used to link the project to the screens comprising theproject.

Screen Table:

The screen table contains a unique ID for a screen in a project. Thescreen is linked to a project by the Project ID. The Screen Tablecontains a Project ID, Screen ID, Screen Name, Screen Type ID and otherscreen attributes. The Screen ID is used to link a screen to objects onthe screen; the Project Id is used to link a Screen to a Project; andthe Screen Type ID is used to link a screen to a screen type. Eachscreen will have a screen type. A screen type is a template thatdescribes the permissible layout for a screen. If a screen has a ScreenType ID, the screen is linked to a Screen Layout which will define thescreen look. Example: Project ID:  004989788 Screen ID:  004000001Screen Name: HomeScreen Screen Type ID: 0000500061

This screen is part of the Project Specified by the Project ID and has ascree type that includes “Lower Buttons” in this example. While that isnot expressly given in the screen table, it is apparent by reference tothe screen type designated by Screen Type ID 0000500061. The objectsassociated with this screen are then read from the screen type and areplaced on the screen as described by the Lower Button Screen Template.

Object Table:

The Object Table contains a Screen Id, which identifies the screen theobject is associated with, a Control ID, which defines the type ofobject and the attributes associated with the object. Example: ScreenID:  004000001 Control ID: 0000000001 Control Type: Video Window

This Video Window object is associated with the Screen identified by theScreen ID and has the attributes that are defined in the Object table.The control is linked to the object table via the Control ID.

Object Info Table:

The Object Info Table contains a Control ID and other control attributeinformation. It is associated with an object via its Control ID.Example: Control ID: 0000000001 Control Type: Video Window Control Name:HomeScreen Video

The Object Info Table provides the attributes associated with an object.In turn the object is associated with a screen via the Screen ID.

Screen Type Table:

The Screen Type Table defines a screen type and the project with whichthis screen type is associated. The Project ID is a unique ID specifyingthe project to which this Type of screen is attached. The Screen Type IDspecifies a specific screen type template.

EXAMPLE

Project ID:  004989788 Screen Type: Lower Button Screen Type ID:0000500061

The Screen Type is a predefined screen layout that can be used todynamically build an interface.

Screen Layouts Table:

The Screen Layouts Table defines the possible layouts for a screen type.It will contain several options for the look of the screen underdifferent circumstances. The Screen Type ID links the screen layouts toa screen type. Example: Screen Type ID: 0000500061 Screen Type: LowerButton 1 Object Coordinates: Rect

The Screen Layout table defines the different appearances available fora screen. The Screen Type Lower Button has a layout that contains thelayout for one Button Object, two Buttons Objects, etc. The systemauthor can then determine how many object are to be placed on a screenand what the screen type is and pick the appropriate coordinates andplace the objects on the screen in a predetermined functional andaesthetic format.

By way of summary, a kiosk user interface authored using the presentsystem includes of the following components: a project component, ascreen component, and a screen object component including buttons, hotspots, video, audio, text, windows for video, audio, text, animation.The project component stores data about the program along with a link toa list of screens in the program as well as the project name and ID. Thescreen component stores information about a specific screen. A screencan contain a background image or solid color, text, a textual referenceto the screen, a screen ID, and the IDs of the parent screen and anychild screens. This arrangement in effect forms a doubly linked listthat allows the system to be displayed in a hierarchy as well as to benavigated in a linear fashion when desirable.

The screen component contains a screen object definition file thatdefines the objects to be placed on the screen. The procedure is asfollows. The first field in the data structure is the Boolean fieldbMath. If bMath is TRUE, then the object locations are ignored and theobjects are placed according to a mathematical formula. This is carriedout as follows. First get the kiosk ID from the definition file. Eachsubscribing client has an ID, and each of the client's kiosks has an ID.Using the unique kiosk ID perform a lookup for data pertinent to thescreen. For example, if the kiosk is at the ABC Ski Shop and the screenis for X Company ski boots, perform a lookup to see what X Company bootsthe ABC Ski Shop carries. Each time an X Company ski boot carried by theABC Ski Shop is found, a counter is incremented. Once the lookup hastraversed the system, the counter will give the total count of X Companyboots at the ABC Ski Shop. Based on this count, a calculation is thenmade to determine where the total count of objects should be placed onthe screen. For example, determine the width and height of the screenand divide each by the total count of objects to determine the space tobe allocated to each object. Then calculate (or lookup) the screencoordinates positioning each object along the lower edge of the screenor, if there are more than, say, seven objects, the lower edge and theleft edge of the screen.

If bMath is FALSE, then the objects are to be placed in predefinedlocations. The database is traversed as before to determine how manyobjects are to be placed on the screen. However, now a screen definitiontable defines where the objects equal in number to the total count areto be placed. In this mode the object locations are predefined.

Once the object locations are determined, the entries in a databasespecify the text and/or pictures associated with the objects. The objectmay then be labeled and drawn. Pseudocode describing this interface isgiven in Table I. TABLE I <Entering new screen - get screen ID passed inas a parameter> Based on Screen ID, look up the screen's objectdefinition file if bMath perform lookup on screen ID to get Lookup Value<e.g., X Company ski boots> Once the lookup key is obtained Read thesystem ID Perform a database lookup based on system ID and lookup key<e.g., ABC Ski Shop AND X Company ski boots> Traverse the system IDlooking for lookup keys Count the matching items Once all objects to beplaced on the screen have been obtained Calculate the object locationsGet screen width Get screen height based on screen width determine xcoordinate of first item Screen Width=1024 There are six objects1024/5=205 Ideal sizing=167 Calculate proper spacing across screen usingobjectWidth=167 Once all object locations are defined perform lookup inthe database using system ID and lookup key With match get “Object Text”get “Picture” get “Video” get “Action” Once the object characteristicsare obtained Label and draw the object else Perform lookup on screen IDto get Lookup Value <e.g., X Company ski boots> Once the lookup key isobtained Read the system ID Perform a database lookup based on system IDand lookup key <e.g., ABC Ski Shop AND X Company ski boots> Traverse thesystem ID looking for lookup keys Count the matching items Once allobjects to be placed on the screen have been obtained Perform a lookupto get the predefined object locations <predefined object locations willdepend on the number of items> Once all the object locations are definedPerform lookup in the database using system ID and lookup key With matchget “Object Text” get “Picture” get “Video” get “Action” Once the objectcharacteristics are obtained Label and draw the object

To implement the kiosk system, a database of all information to bedisplayed at any individual kiosk is constructed. The database is formedusing standard database methods and software. In the illustratedembodiment Btrieve database software was used to create and maintain thedatabase. The method of the invention is implemented so that othercommercial database software products could readily be substituted forBtrieve. The authoring system of the present invention then allows eachkiosk to be customized quickly and easily while maintaining a highdegree of variability in the screen layouts without sacrificingaesthetic appearance. Unlike authoring systems of the prior art, whichgenerally create a specific version of the software for each kiosk, thepresent authoring system uses the same software at each kiosk, butmerely redefines definition tables to configure an individual kiosk. Thedefinition tables can be redefined at the kiosk site or remotely frommaster computer 13. In this way for example when a ski shop stopsproviding one ski line and substitutes a competitor's ski line, it isonly necessary to change a definition table to update the kioskinterface. No change in the software is called for.

A description is now given of the organization of the database ofinformation available to be displayed on a kiosk screen in the exampleof FIG. 2A. FIG. 4 shows an example of a joined table structure that isused to describe the category of resorts. The joined table is a seriesof related tables describing the resorts and their offerings. By usingthe information in these tables in conjunction with the information inScreen Layout tables discussed above, a system author can create a userinterface on the fly, i.e, in real time, instead of having to pre-defineeach screen specific to each kiosk. For example, to prepare the userinterface for a kiosk in the California Region, one performs a lookup inthese tables using the database software to determine the resorts in thedatabase for California. This gives a count of the number of resorts inthe California region, which may then be laid out on the screen.Performing lookups through the joined table structure providesinformation for developing the further hierarchical screen layoutincluding information for each resort, ski runs, rental shops,restaurants and the like.

We turn now to a description of the individual tables making up thejoined table of FIG. 4.

The Region Table:

The region Table provides a unique Region ID as well as a Region Name.The Region ID is a unique long integer. Any scheme may be used fordefining IDs occurring in this and all the other tables of the database.The Region Name provides a descriptor for the Region. Example: RegionID: 000909100 Region Name: California Region ID: 000800101 Region Name:Pacific North West

All resorts are associated with a region. One performs a lookup of thenumber of Regions in the system to determine how many buttons shouldappear on the Region Screen. To place the buttons on the screen, eithera screen layout associated with a predefined screen type may be used ora mathematical formula may be used to position a standard button alongthe bottom or side of the screen as in FIG. 2A.

Resort Table:

The Resort Table provides a Unique Resort ID, a Resort Name, a RegionID, and other information about the resort such as the number of chairlifts, the number of Runs, whether the resort has other Facilities orActivities. The Resort ID is a unique identifier for a specific resort,and the Region ID defines an association provided through a join to aRegion. As implemented here, all resorts are found within one Region.The rest of the information in this table gives general informationabout the resort. Example: Resort ID: 000909190 Resort Name: BigMountain Ski Area Region ID: 00909100 Number of Runs: 110 Number ofChairs: 34 Facilities True Activities True

This information is used to determine the screen layout. If a Region hasfour resorts linked to it, then the screen will have four correspondingbutton objects. As indicated above, the button objects can be placed onthe screen either by mathematical formula giving screen coordinates orby screen type. If the Resorts screen has a screen type associated withit, then the screen layout will be looked up based on the number ofResorts associated with a Region.

Chair Lift Table:

The Chair Lift Table provides a Unique Resort ID, a Chair ID and a ChairName. The Resort ID links the Chair Lift to a specific resort and theChair ID links the Chair to a record in the Chair Lift Info table. TheChair lift Name provides the common name of the lift. Example: ResortID: 000909190 Chair ID: 000000001 Chair Name: SiberiaChair Lift Info Table:

The Chair Lift Info Table provides a Unique Chair ID, a Chair Name andother information about the chair such as vertical rise and terrainserved. Example: Chair ID: 000000001 Chair Name: Siberia Lift Type:Express Quad Hourly Capacity: 2600 Skier/hour Vertical: 1600′ Length:5000′ Terrain Served: Intermediate/AdvancedRun Table:

The Run Table provides a Chair ID and a Unique Run ID as well as the SkiRun name. The Chair ID links this run to a chair and the Run ID linksthis run to more extensive information about the run. Example: Chair ID:000000001 Run ID: 001000100 Run Name: The WallRun Info Table:

The Run Info Table provides a Unique Run ID, a Run Name and otherinformation about the Runs. The Run ID links a run record to a specificrun. Example: Run ID: 001000100 Run Name: The Wall Level: AdvancedLength: 5000′ Vertical 1600′Facilities Table:

The Facilities Table provides a Unique Resort ID, a Facility ID and aFacility Name. The Resort ID links a Facility to a resort, the FacilityID links the Facility to a Facility Record and the Name is the commonname of the Facility. Example: Resort ID: 000909190 Facility ID:001000010 Facility Name: Ski Rental

When creating the Resort Facilities Screen, the number of facilitiesassociated with the resort may be looked up in this table to determinethe screen layout.

Facility Info Table:

The Facility Info Table provides a Unique Facility ID and furtherdescriptive and informational items. The Facility ID links this recordto the Facilities Table. Example: Facility ID: 001000010 Facility Name:Ski Rental Costs: — Hours: 7:30-5:30 Daily

The Facility Info table is used to label the Button Objects, todetermine the button image, and to associate data with a button so thatwhen a user activates the button, the correct action will be initiatedsuch as filling a text window or running an appropriate video.

Activities Table:

The Activities Table provides a Unique Resort ID, a Facility ID and anActivity Name. The Resort ID links an Activity to a specific resort, andthe Activity ID links an Activity to an Activity Record. Example: ResortID: 000909190 Activity ID: 002000001 Activity Name: Swimming

When laying out the Resort Activities Screen, the number of activitiesassociated with the resort is looked up to determine the screen layout.

Activities Info Table:

The Activities Info Table provides a Unique Activity ID and otherinformation about the Activity. The Activity ID links an Activity to arecord about that activity. Example: Activity ID: 002000001 ActivityName: Swimming Hours: 9-5 Daily Cost: $10 per day

The Activity Info table is used to label the Button Objects, determinethe button image and associate data with a button so that when a useractivates the button, the correct action will be initiated such asfilling a text window or running an appropriate video.

We turn now to a description of the individual tables making up theshops and manufacturers joined table of FIG. 5. This series of tablesdescribes the equipment side of the kiosk system that links ski shops toski equipment manufacturers and their products. The user interface for akiosk in a ski shop may be created on the fly from the information inthese tables. For example, for a kiosk in the ABC Ski Shop the Shopstable will be linked to the manufacturer table and the manufacturerproducts table (referred to as Shop Items). The joined table providesthe content for the Shop. The screen for the ABC Ski Shop will bepopulated based on the information in the joined table by performing alookup of the Manufacturers and the type of associated information tocreate the interface. If the ABC Ski Shop carries skis from X Company,for example, then an X Company Ski Button will be placed on the screen.A significant point here is that the information about X Company skis isalready in the database. It is only necessary that a table entry beincluded to indicate that the ABC Ski Shop carries X Company skis. Asbefore, the appropriate number of button objects are placed according toa predefined screen type or by mathematical algorithm specifying screencoordinates.

The individual tables comprising FIG. 4 will now be described.

Shop Table:

The Shop Table provides a Unique Shop ID, a shop name and address. TheShop ID provides a link to the Shop Items database. Example: iShop: 0001sShop: ABC Ski Shop

Based on the Shop ID a table lookup may be performed in the ShopsItemdatabase. This will allow the system author to determine the items theshop carries. The Shop Table will generally also include addressinformation and in particular may include a telephone or fax line, whichcan be used for downloading and uploading information with the kiosk.

Shop Items Table:

The ShopItems table provides a Unique Item ID, a reference to the shopand a boolean value indicating whether the shop carries the item. If theshop carries the item, a table lookup can be performed in the Itemstable to obtain the attributes of the item or information about thatitem. Example: iItem: 00001 iShop:  0001 fAvailable: True

Based on the item ID and the boolean value, information can be gatheredabout the shops inventory.

Items Table:

The Items table contains all items from all manufacturers. The tableincludes an item ID, which specifies what the item is, an ItemType,which specifies what the type is, and a Manufacture ID, which specifieswhat Manufacture makes that Item. Example: iItem: 00001 iItemType: 00100iManufacture: 10000 sItem: Skis Male: Male or Female sSizeForm: Sizes

This table links all the items to the shop and manufacturers.

Item Type Table:

The table contains an Item Type ID and a description. The Item Type IDlinks an item type to an item. Example: iItemType: 00100 sItemType:Alpine Skis

This table links an item to an item type.

Manufacturer Table:

The Manufacturer table contains information on all manufacturers. Itincludes a unique Manufacturer ID, address information and any otherrelevant information. Example: iManufacture: 10000 sManufacture: XCompany sAddress: — sCity: — sState: — sCounty: —

The Manufacturer ID links an item to the Manufacturer of that item.

The authoring system is implemented in the embodiment illustrated hereby means of a C++ interface to access the fields of the database asdefined in the above sample tables. Standard Btrieve calls are used toaccess database. Software code generally referred to as a wrapper iswritten around the Btrieve API for linking the C++ interface to theBetrieve calls. The generation of such code is routine given the benefitof the disclosure herein and need not be described in detail here.Nevertheless here is a sample of such code.

The following are all member variables from the CMADbase Class.

Public data members: BTIWORD m_datalen; BTI_BYTE m_keyBuf[255]; BTI_SINTm_status Private data memebrs: BTI_BYTE posBlock[128]; BTI_BYTEdataBuf[255]; BTI_WORD dataLen; BTI_WORD keyNum=0; BTI_SINT statusunsigned char m_fileOpen=FALSE;

These are structures defined for the Btrieve Records struct { FILE_SPECSfileSpecs; KEY_SPECS keySpecs[2]; } fileCreateBuf; Member FunctionsFunctioin Name: Open Description: Provide a wrapper for Btrieve OpenFile function BOOL CMADBase::Open(CString sFileName) {strcpy((BTI_CHAR*)m_keyBuf, sFileName); m_keyNum=0;m_datalen=sizeof(fileCreateBuf); m_status=BTRV(B_OPEN, m_posBlock,m_dataBuf, &m_datalen, m_keyBuf, m)keyNum); if (m_status= =B_NO_ERROR) {m_fileOpen=TRUE; return TRUE; } else { DisplayError(m_status); returnFALSE; } }

Functin Name: Close

Description: Provide a wappar for the Btrieve Close File function BOOLCMADbase::Close( ) { if (m_fileOpen) { m_dataLen=0;m_status=BTRV(B_CLOSE, m_posBlock, m_dataBuf, &m_dataLen, m_keyBuf,m_keyNum); if (m_status = = B_NO_ERROR) { return TRUE; } else {DisplayError(m_status); return FALSE; } } return FALSE; }

Providing wrapper functions around the Btrieve code gives theflexibility to switch to a differenct database in the future. When a newdatabase is introduced, it is only necessary to change these wrapperfunctions. The code in the rest of program does not have to be altered.

The manner disclosed herein for defining a user interface for a specifickiosk has the advantage that to change the interface one need onlyperform a database lookup and fill out definition files for each kiosk.When the ABC Ski Shop first decides to place a kiosk in the shop, an ABCkiosk definition table is filled out for the ABC Ski Shop and enteredinto the database. The kiosk interface screens may then be quicklydefined from database lookups. At a later time if the ABC Ski Shopshould sell out of a model of X Company ski boots, that item can beremoved from the definition table and the affected interface screenre-defined to remove any buttons or other objects that may have beenassociated with the sold-out item.

As mentioned above, when a central database server is not used, it isadvantageous for each kiosk to contain the complete database, evenincluding tables that will not be used at that kiosk. When the databasetables are modified, for whatever reason, the modified database can bedownloaded to each kiosk in the system. The advantages following fromthis are as follows. Version control: uncontrolled propagation ofmultiple version throughout the kiosks in the field is prevented. Theneed to keep track of which version each kiosk has is avoided. In thismanner it is also easier to keep comply with contractual obligations tokeep each subscriber updated with the latest version. Kiosk portability:A kiosk unit may be moved from one subscriber to another with no changeof software or reconfiguration other than providing a definition file.Control over changing information providers: A ski shop may drop oneline of product for a competitor's line. The ski shop's kiosk willalready be configured for the full range of information providers. It isthen only necessary to change a definition file. Loading and unloadingof a multiplicity of information provider files is avoided.Broadcasting: It is easier to broadcast messages, for example, when XCompany runs out of or discontinues a particular ski, this change can bemade once and broadcast to all subscribers. Local and remoteconfiguration: The local layout for a particular kiosk subscriber can beconfigured either at the subscriber's location or remotely. This wouldnot be feasible if the full database were not available at thesubscriber's kiosk.

The above descriptions and drawings disclose illustrative embodiments ofthe invention. Given the benefit of this disclosure, those skilled inthe art will appreciate that various modifications, alternateconstructions, and equivalents may also be employed to achieve theadvantages of the invention. For example, given the benefit of thisdisclosure, those skilled in the art will be able to implement kiosks inother subject areas than skiing and skiing-related subjects, which isonly offered as an example. Therefore, the invention is not to belimited to the above description and illustrations, but is defined bythe appended claims.

1. In a kiosk system having a plurality of kiosks for displayinginformation from a database of information provided by a plurality ofinformation providers, wherein each kiosk includes a display monitor forthe display of information to a user and an associated microprocessorfor controlling the retrieval and display of information, a method fordefining custom interface screens for an individual kiosk comprising thesteps of: providing a plurality of pre-defined element types, eachelement type defining a form of element available for presentation onsaid custom interface screen and each element type having a plurality ofattributes associated therewith wherein each said attribute may beassigned a value in a pre-defined attribute range; selecting a pluralityof elements to be displayed on said custom interface screen, saidplurality of elements being selected from said plurality of predefinedelements types, said predefined plurality of elements including at leastone activation type; assigning values to the attributes associated witheach of said selected elements, said attributes values being assignedwithin said predefined attribute ranges, wherein said selected elementson said display screen are subject to a predefined set of constraintsdetermined by said pre-defined element types and said associatedattribute values and attribue ranges, whereby the aggregate layout ofsaid plurality of selected elements on said display screen will beaesthetically pleasing and functionally operable for effective deliveryof information to a kiosk user; associating content bearing data witheach of said selected elements, wherein said content bearing dataassociated with at least a portion of said selected elements is derivedfrom said information providers; and linking said at least one selectedactivation type to an action.